InfoMagic Internet Tools 1993 July/Internet Tools.iso/RockRidge/mail/pine/imap_archive/text0018.txt

Text File | 1993-07-02 | 6.2 KB | 125 lines

>>    This is becoming a real issue for us.  The ability to get and
>>configure services like delivery acknowledgement, read
>>acknowledgments, and automatic reply are a high priority for many of
>>our clients - especially when packages like Microsoft mail are able to
>>do it.
>Delivery acknowledgements are useless (the message will bounce if not
>delivered).  Read acknowledgements, and reply are client issues.  If
>by "automatic reply" you mean something like the unix vacation
>service, we have that rated as "NICE" meaning we'll consider it if we
>get time (I think putting support for it in either the management
>protocol or the user directory protocol is reasonable).

Delivery acknowledgements are not useless.  It is an unfortunately
true fact that not all the MTAs on the Internet are robust.  This is
much less true than in the past, but is still true.  If you are sending
messages to someone and do not have confidence that they're being
delivered (and are getting no response from the recipient), you're
in a very frustrating situation.  You do not know why s/he isn't responding
and may get mad at them when it isn't their fault.  With delivery
acknowledgements you know when to get mad at them ;-).

Is the way these message-store-ish things are implemented an issue?  In our
product the UA fiddles directly with a PP-style ".mailfilter" file (our
MTA is based on PP) in order to configure these kind of services.

>>5.  There was some mention on work being done to implement
>>lightwieght directory access protocols for getting X.500 information
>>quickly.  Could someone point me to these individuals again?  This is
>>very important to us as a mechanism for distributing public keys for
>>PEM.
>There's a protocol called CSO/ph which we're going to look into.  If
>it's not good enough, we'll design & write our own.

There are others, but I don't remember any RFC numbers.  In our product
we're using one of these protocols and it's nice to be able to pull in
addresses from the directory with few hassles.  But we're not satisfied
with the kinds of requests we can make from the directory, this protocol
is heavily geared towards finding *people* and we're wanting to build
other products based on the X.500 directory.

GREPing through RFC-INDEX.TXT is recommended.  The only name which
comes to mind is "DIXIE".


<- David Herron <[e-mail]> (work) <[e-mail]> (home)
<-
<- During the '80s Usenet's mantra was: "Not all the world's a VAX".
<- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
From [e-mail]  Mon Sep 28 11:01:14 1992
Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA04932; Mon, 28 Sep 92 11:01:14 -0700
Received: by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA08159; Mon, 28 Sep 92 11:01:05 -0700
Errors-To: [e-mail]
Sender: [e-mail]
Received: from olive.cac.washington.edu by mx1.cac.washington.edu
    (5.65/UW-NDC Revision: 2.27 ) id AA08153; Mon, 28 Sep 92 11:01:04 -0700
Received: by olive.cac.washington.edu
    (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.21 ) id AA11249; Mon, 28 Sep 92 10:56:25 PDT
Date: Mon, 28 Sep 1992 10:47:25 -0700 (PDT)
From: Laurence Lundblade <[e-mail]>
Reply-To: Laurence Lundblade <[e-mail]>
Subject: Re: Re: Some general mail message issues
To: David Herron <[e-mail]>
Cc: Chris Newman <[e-mail]>, Steve Hole <[e-mail]>,
        [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

There was a mailing list to discuss the delivery acknowledgements:
[e-mail]. I think it's inactive now, but things got pretty
sticky when trying to make it work across all the different things
connected on the "greater Internet" (BITNET, VAXMail, MCI Mail, gateways
to Microsoft mail....). It seems very possible that with such a system
often the mail would arrive, but it's arrival would very often not be
acknowledged. At least until there was a standard that we all agreed on.
Microsoft mail and such have an advantage (disadvantage as well of course)
in that they're closed systems.

Right now sendmail has a "Return-Receipt-To:" header that will do this,
but no guarantees it will work with anything else!

Laurence Lundblade                       206-543-5617
  [e-mail]
     Computing and Communications, University of Washington, Seattle


On Mon, 28 Sep 1992, David Herron wrote:

> Date: Mon, 28 Sep 92 10:34:43 PDT
> From: David Herron <[e-mail]>
> To: Chris Newman <[e-mail]>
> Cc: Steve Hole <[e-mail]>, [e-mail]
> Subject: Re: Re: Some general mail message issues
>
> >>    This is becoming a real issue for us.  The ability to get and
> >>configure services like delivery acknowledgement, read
> >>acknowledgments, and automatic reply are a high priority for many of
> >>our clients - especially when packages like Microsoft mail are able to
> >>do it.
> >Delivery acknowledgements are useless (the message will bounce if not
> >delivered).  Read acknowledgements, and reply are client issues.  If
> >by "automatic reply" you mean something like the unix vacation
> >service, we have that rated as "NICE" meaning we'll consider it if we
> >get time (I think putting support for it in either the management
> >protocol or the user directory protocol is reasonable).
>
> Delivery acknowledgements are not useless.  It is an unfortunately
> true fact that not all the MTAs on the Internet are robust.  This is
> much less true than in the past, but is still true.  If you are sending
> messages to someone and do not have confidence that they're being
> delivered (and are getting no response from the recipient), you're
> in a very frustrating situation.  You do not know why s/he isn't responding
> and may get mad at them when it isn't their fault.  With delivery
> acknowledgements you know when to get mad at them ;-).
>
> Is the way these message-store-ish things are implemented an issue?  In our
> product the UA fiddles directly with a PP-style ".mailfilter" file (our
> MTA is based on PP) in order to configure these kind of services.
>